@yersan this adds an option to reject the update/revert if any file conflicts are detected, like we talked last week.

@spyrkob Question, as long as there is a deployment, the standalone.xml / domain.xml will be modified; it means that practically 100% of the installations will generate a conflict when copying these configuration files (and other files used to tweak the launch script environment).

How does Prospero work in that regard? I mean, if the update does not contain any configuration file change (as it should be), would a conflict be detected always when the full structure of the candidate server is applied?

If so, it sounds reasonable to exclude from the conflict checks the files that are expected can be modified by the user. So, even if --no-conflicts-only is used and there is a conflict on standalone.xml / domain.xml, then they will be ignored because the conflict is expected on some files.

It would be great if we have the possibility to just check the conflicts by using a candidate server without the apply or perform actions. The advantage would be that will allow the users to check possible conflicts without stopping the server first, and then decide if they want to continue. There won't be guarantees to not hit a conflict later, but if you, before shutting down the server, are able to check the conflicts, then an immediate shutdown to apply the update would be safer and would avoid shutting down from update later because you have a conflict you want to investigate or be sure it is safe for you.

How does Prospero work in that regard? I mean, if the update does not contain any configuration file change (as it should be), would a conflict be detected always when the full structure of the candidate server is applied?

The conflicts only occur if both the user and the incoming update changes the same file. If only the user changed a file, this file will be preserved. If only the update modified the file, the file will be updated. If the file was modified in both, the resolution via .glold/.glnew will be done.

It would be great if we have the possibility to just check the conflicts by using a candidate server without the apply or perform actions. The advantage would be that will allow the users to check possible conflicts without stopping the server first, and then decide if they want to continue. There won't be guarantees to not hit a conflict later, but if you, before shutting down the server, are able to check the conflicts, then an immediate shutdown to apply the update would be safer and would avoid shutting down from update later because you have a conflict you want to investigate or be sure it is safe for you.

Sure we can add a method like checkCandidate that will check if it can be applied, what artifacts are updated, if there are any FileConflicts, etc. Not sure if that's also needed on command line, but if so we can add a new subcommand like update check-candidate

Not sure if that's also needed on command line

At Prospero command line, it could be useful if you are trying to minimize the downtime and you want to reject any conflicts.
It would be as a check before stopping the server to apply the generated candidate server to be sure that what you want to apply won't be rejected if there are conflicts.

I'll add this functionality to this PR next week

@yersan FYI I added a verifyCandidate that check if the candidate is valid (i.e. if it is a candidate for the desired opertion, if it can be applied etc) and returns a list if file conflicts together with their proposed resolutions.